The
mail-parse library is an abstraction over the actual
low-level libraries that are described in the next chapter.
Standards change, and so programs have to change to fit in the
new mold. For instance, RFC2045 describes a syntax for the
Content-Type header that only allows
ASCII characters in the parameter list.
RFC2231 expands on RFC2045 syntax to provide a scheme for
continuation headers and non-ASCII
characters.
The traditional way to deal with this is just to update the library functions to parse the new syntax. However, this is sometimes the wrong thing to do. In some instances it may be vital to be able to understand both the old syntax as well as the new syntax, and if there is only one library, one must choose between the old version of the library and the new version of the library.
The Emacs MIME library takes a different
tack. It defines a series of low-level libraries
(rfc2047.el,
rfc2231.el and so on) that
parses strictly according to the corresponding standard. However,
normal programs would not use the functions provided by these
libraries directly, but instead use the functions provided by the
mail-parse library. The functions in this library
are just aliases to the corresponding functions in the latest
low-level libraries. Using this scheme, programs get a consistent
interface they can use, and library developers are free to create
write code that handles new standards.
The following functions are defined by this library:
mail-header-parse-content-typeContent-Type header and return a list on the
following format:
("type/subtype"
(attribute1 . value1)
(attribute2 . value2)
...)
Here's an example:
(mail-header-parse-content-type
"image/gif; name=\"b980912.gif\"")
⇒ ("image/gif" (name . "b980912.gif"))
mail-header-parse-content-dispositionContent-Disposition header and return
a list on the same format as the function above.mail-content-type-get
(mail-content-type-get
'("image/gif" (name . "b980912.gif")) 'name)
⇒ "b980912.gif"
mail-header-encode-parameterContent-Type and
Content-Disposition.mail-header-remove-comments
(mail-header-remove-comments
"Gnus/5.070027 (Pterodactyl Gnus v0.27) (Finnish Landrace)")
⇒ "Gnus/5.070027 "
mail-header-remove-whitespace
(mail-header-remove-whitespace
"image/gif; name=\"Name with spaces\"")
⇒ "image/gif;name=\"Name with spaces\""
mail-header-get-comment
(mail-header-get-comment
"Gnus/5.070027 (Pterodactyl Gnus v0.27) (Finnish Landrace)")
⇒ "Finnish Landrace"
mail-header-parse-address
(mail-header-parse-address
"Hrvoje Niksic <hniksic@srce.hr>")
⇒ ("hniksic@srce.hr" . "Hrvoje Niksic")
mail-header-parse-addresses
(mail-header-parse-addresses
"Hrvoje Niksic <hniksic@srce.hr>, Steinar Bang <sb@metis.no>")
⇒ (("hniksic@srce.hr" . "Hrvoje Niksic")
("sb@metis.no" . "Steinar Bang"))
mail-header-parse-datemail-narrow-to-headmail-header-narrow-to-fieldmail-header-fold-fieldmail-header-unfold-fieldmail-header-field-valuemail-encode-encoded-word-regionmail-encode-encoded-word-buffermail-encode-encoded-word-string
(mail-encode-encoded-word-string
"This is naïve, baby")
⇒ "This is =?iso-8859-1?q?na=EFve,?= baby"
mail-decode-encoded-word-regionmail-decode-encoded-word-string
(mail-decode-encoded-word-string
"This is =?iso-8859-1?q?na=EFve,?= baby")
⇒ "This is naïve, baby"
Currently, mail-parse is an abstraction over
ietf-drums, rfc2047,
rfc2045 and rfc2231. These are
documented in the subsequent sections.